Skip to content

Conversation

@fern-api
Copy link
Contributor

@fern-api fern-api bot commented Feb 10, 2026

Reorganized the construe upload API to simplify request structure and improve
asynchronous processing flow. Removed user_id fields from multiple template
types across the SDK to streamline data models.

Key changes:

  • Simplified upload request structure with unified UploadRequest interface
  • Changed upload behavior to always return 202 and process asynchronously
  • Removed user_id fields from ChatMessageTemplate, ChatSessionTemplate, and other templates
  • Updated documentation to reflect asynchronous processing model
  • Reorganized type exports and moved UploadRequest to client/requests directory
  • Added name and version fields to upload response for better tracking

🌿 Generated with Fern


Note

Medium Risk
Introduces breaking type/model changes and changes the upload request/response contract for uploadCodeSystem, which may require downstream code updates despite being largely SDK-surface refactoring.

Overview
Bumps the SDK to 6.0.0 and refactors construe.uploadCodeSystem to use a single UploadRequest type (moved under construe/client/requests) with a format enum and optional CSV/JSON-specific fields, removing the prior format-specific union types and the async upload flag.

Updates behavior/docs/tests to reflect uploads being always asynchronous (returning immediately with processing status and requiring polling for readiness), and expands ConstrueUploadCodeSystemResponse to include name and version. Removes user_id from multiple template/response models (agent chat messages/sessions, FHIR provider templates, summary templates, MCP server/tool responses, workflows) and adjusts wire tests accordingly.

Written by Cursor Bugbot for commit d9db363. This will update automatically on new commits. Configure here.

Reorganized the construe upload API to simplify request structure and improve 
asynchronous processing flow. Removed user_id fields from multiple template 
types across the SDK to streamline data models.

Key changes:
- Simplified upload request structure with unified UploadRequest interface
- Changed upload behavior to always return 202 and process asynchronously
- Removed user_id fields from ChatMessageTemplate, ChatSessionTemplate, and other templates
- Updated documentation to reflect asynchronous processing model
- Reorganized type exports and moved UploadRequest to client/requests directory
- Added name and version fields to upload response for better tracking

🌿 Generated with Fern
Copy link

@cursor cursor bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Cursor Bugbot has reviewed your changes and found 1 potential issue.

Bugbot Autofix is OFF. To automatically fix reported issues with Cloud Agents, enable Autofix in the Cursor dashboard.

file: "file",
code_col: "code",
desc_col: "description",
};
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Test mocks 200 but API now returns 202

Low Severity

The happy-path test for uploadCodeSystem mocks a statusCode(200) response, but the documentation, code comments, and PR description all state the endpoint now always returns 202 to indicate asynchronous processing. The response body was correctly updated (from "success" to "processing"), but the status code was not changed to match. This means the test doesn't validate the actual wire behavior of the 202 async flow.

Additional Locations (1)

Fix in Cursor Fix in Web

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

0 participants